Various service providers (e.g., financial institutions, banks, brokers, merchants, etc.) are often involved in transactions requiring the identification and validation of a remote entity (e.g., an individual, organization, smart card, message, account, etc.) and the certification of transaction data. These service providers often provide their services to remote entities over the Internet in what is often referred to as electronic commerce (e-commerce). One of the limitations of e-commerce is that the remote entity requires a personal computer or similar device to complete the transaction. In addition, the remote entity requires the necessary skills for utilizing the Internet.
Recently, there have been intense efforts to develop technology for bridging the gap to remote entities that do not have access to the Internet in order to make e-commerce more widely available. This emerging technology (e.g., Web Telephony Engine of Microsoft) often makes use of a voice browser. A voice browser is software that executes on a personal computer or similar device, and “understands” spoken instructions by utilizing speech recognition technology and “reads out” text by using text-to-speech technology. The voice browser is used by a remote entity to browse the internet over a voice line such as a telephone line. Thus, voice browsers enable a remote entity to perform an internet transaction over a phone. In order to identify himself, the caller or consumer can use a smart card, or other known technology. However, these identification activities are limited in that additional hardware is required (e.g., a card reader) and certain telephones (e.g., public phones) cannot be utilized.
Regardless of whether the transaction takes place over a telephone, the Internet (including voice over IP) or other telecommunications media, it is important for service providers to ensure during each transaction that the remote entity is not an impostor. Accordingly, service providers often employ various identification devices to identify and validate remote entities, these devices being referred to herein as Identification Devices. For ease of discussion, a remote entity authorized to engage in transactions, but perhaps not yet identified and/or authenticated by an Identification Device for a particular transaction, is referred to herein as an “Authorized Remote Entity” or “Authorized Entity.”
One method commonly known in the art and employed by Identification Devices for securely identifying a remote entity is to add “authentication” to an otherwise normal identification process. Authentication is typically accomplished by providing an additional piece of information to an Identification Device, e.g., a secret code, along with identification information. This additional information then may be used to corroborate that the identification is accurate and that the remote entity is not an impostor attempting to impersonate an authorized entity. The additional piece of information is often a secret code or a password (e.g., PIN), but also may be a Dynamic Code, preferably computed using a software implemented algorithm. Alternatively, the additional information may be provided by a token (e.g., Bio-Token) carried by the entity (e.g., individual) to be identified.
Non-variable (i.e., constant or static) information or data (e.g., PIN) can only add limited security to the identification process because a static piece of information eventually may become known to a third party (e.g., potential attacker/impostor/eavesdropper) in which case an authorized entity can easily be impersonated. On the other hand, authentication by means of a variable piece of information (referred to herein as a Dynamic or One Time Code) provides enhanced security.
Currently known methods of authentication which use a Dynamic or One Time Code typically require a prior step of identifying the remote entity to the Identification Device, e.g., by providing a name (e.g., a login name), a serial number, an additional fix code, etc. as part of a message transmitted from a Remote Entity to an Identification Device. This constant part of a message will be referred to herein as an Identification Message. Thus, a method commonly employed by an Identification Device to securely identify a Remote Entity by authentication typically comprises the three following steps:
1) Identification: identify who the Remote Entity is supposed to be, by receiving a constant (non-variable, or at least non-constantly-variable) piece of information, referred to herein as an Identification Message;
2) Database Search: the Identification Devices searches a database containing the Authorized Entity's secret information or computing keys, to compute a dynamic piece of information (referred to herein as a Valid Dynamic Code) which is associated with and expected from the Authorized Entity at that particular moment; and
3) Authentication: the Identification Device compares the Valid Dynamic Code (computed at the Identification Device) with a Dynamic Code received from the Remote Entity (referred to as the Received Dynamic Code) to check if both codes match; if so, the Identification Device corroborates the identification of the Remote Entity as being the Presumed Entity.
A variation of the above-described authentication method is referred to as the Challenge and Response method, comprising the following steps:
1) The Remote Entity is identified (as described in step 1 above);
2) The Remote Entity receives a Challenge generated and sent by the Identification Device and computes a Response, the Response playing the role of a Dynamic Code;
3) The Identification Device, after identifying the Remote Entity (the Pre-Authentication Identification), searches a database containing the Authorized Entity's secret information or computing keys, to determine the expected response to the challenge, for that Remote Entity at that moment.
Each of the authentication schemes described above requires the Identification Device to employ a database or look-up table. Naturally, each database must be maintained and updated, which creates problems associated with the management of keys, synchronized database updates, etc. Furthermore, these problems become acute when a service provider utilizing an authentication process has a multitude of Identification Devices disseminated through several countries.
Another problem associated with conventional schemes for Remote Identification is the possibility of “repudiation” by an identified and authenticated Remote Entity. For example, a Remote Entity, which has been identified and authenticated as being an Authorized Entity, may later deny the genuineness of a particular communication or event under scrutiny. To illustrate, in the case of a Gambling Service Provider (although identification and authentication techniques may apply to any service provider, Gambling Service Providers are used for this example), Remote Entities (e.g., gamblers) may place bets from remote locations and pay for those bets using Credit Cards. Naturally, before a particular Remote Entity places any bets, the Gambling Service Provider identifies and authenticates that Remote Entity by a procedure similar to those described above. Once the bets have been placed, one of the Remote Entities wins a prize, while all of the remaining Remote Entity gamblers lose. This situation presents an opportunity for any number of losing Remote Entities to repudiate their particular betting transaction, including the identification and authentication process, claiming that they never made the transaction/bet, and that the Gambling Service Provider fabricated the transaction or made a mistake. Because each Remote Entity is authenticated by the Provider's Identification Device, and further because the provider includes a database containing secret information, the Provider has the capability to compute as many Valid Dynamic Codes as the Gambling Service Provider may desire, and an unscrupulous Gambling Service Provider thereby has the ability to fabricate transactions. Accordingly, when a Remote Entity repudiates a transaction, there is no way to prove whether the Gambling Service Provider fabricated the transaction or the Remote Entity has repudiated a valid transaction. Of course, if all the losing Remote Entities repudiate their transactions, the effect on the Gambling Service Provider may be disastrous.
As illustrated in the example above, present methods of authentication intrinsically are subject to the negative effects of transaction repudiation, due to the fact that the receiving/identifying/authenticating side of each transaction has the capability to compute a secret Dynamic Code as accurately as the Remote Entity.
A further drawback of authentication methods known in the art and described above is the fact that a Remote Entity is trackable. In other words, an eavesdropper may follow every transaction made a particular Remote Entity because that Remote Entity transmits the same constant identification information for every transaction. This ability to track a Remote Entity creates a lack of security and privacy for many Remote Entities (e.g., especially government officers, ministers, police officers, etc.).
In addition, another problem encountered is the impersonation of a service provider by a third party. For example, a third party may impersonate a service provider in order to obtain information from the remote entity without the remote entity's knowledge. The third party may then use the obtained information to complete transactions to the detriment of the remote entity.
Thus, a new method and apparatus for the identification of a remote entity is needed that overcomes the limitations and problems of the prior art.